| Internet protocol suite |
|---|
| Application layer |
| Transport layer |
| Internet layer |
| Link layer |
SOCKet Secure (SOCKS) is an Internet protocol that routes network packets between a client and server through a proxy server. SOCKS5 additionally provides authentication so only authorized users may access a server. Practically, a SOCKS server will proxy TCP connections to an arbitrary IP address as well as providing a means for UDP packets to be forwarded.
SOCKS performs at Layer 5 of the OSI model—the session layer (an intermediate layer between the presentation layer and the transport layer).
Contents |
The protocol was originally developed by David Koblas, a system administrator of MIPS Computer Systems. After MIPS was taken over by Silicon Graphics in 1992, Koblas presented a paper on SOCKS at that year's Usenix Security Symposium and SOCKS became publicly available.[1] The protocol was extended to version 4 by Ying-Da Lee of NEC.
The SOCKS reference architecture and client are owned by Permeo Technologies[2] a spin-off from NEC. (Blue Coat Systems bought out Permeo Technologies).[3][4]
The SOCKS5 protocol was originally a security protocol that made firewalls and other security products easier to administer. It was approved by the IETF in 1996.[5] The protocol was developed in collaboration with Aventail Corporation, which markets the technology outside of Asia.[6]
Some SSH clients support dynamic port forwarding that allows the user to create a local SOCKS proxy. This can free the user from the limitations of connecting only to a predefined remote port and server.
The Tor onion proxy software presents a SOCKS interface to its clients.
Another use of SOCKS is as a circumvention tool, allowing to bypass Internet filtering to access content otherwise blocked by governments, workplaces and schools.[7]
In the 1990s, SOCKS was widely deployed in corporate environments as a circuit-level gateway, later largely replaced by packet filter and stateful firewalls.
SOCKS operates at a lower level than HTTP proxying: SOCKS uses a handshake protocol to inform the proxy software about the connection that the client is trying to make and may be used for any form of TCP or UDP socket connection, whereas an HTTP proxy takes an HTTP request and forwards it to an HTTP server. Though HTTP proxying has a different use-case in mind, the CONNECT[8] method allows one to forward TCP connections, there is however no mechanism for UDP proxying. The following examples show the difference between the two methods:
Bill wishes to communicate with Jane over the internet, but a firewall exists on his network between them. Bill is not authorized to communicate through it himself. He connects to the SOCKS proxy on his network and sends it information about the connection he wishes to make to Jane. The SOCKS proxy opens a connection through the firewall and facilitates the communication between Bill and Jane. For more information on the technical specifics of the SOCKS protocol, see the sections below.
Bill wishes to download a web page from Jane, who runs a web server. Bill cannot directly connect to Jane's server, as a firewall has been put in place on his network. In order to communicate with the server, Bill connects to his network's HTTP proxy. His web browser communicates with the proxy in exactly the same way it would with the target server—it sends a standard HTTP request header. The HTTP proxy reads the request and looks for the Host header. It then connects to the server specified in the header and transmits any data the server replies with back to Bill.[9]
Many company and university network administrators set firewall rules that prevent users from connecting to any internet service apart from webpages. Both the SOCKS and HTTP proxy protocols can be used to pierce these firewalls. SOCKS is usually used to create a raw TCP connection, and the HTTP proxy protocol can do the same with the CONNECT method. In both cases a TCP connection is created from the client to the proxy server, and the IP address and port to which the client requests a connection is communicated over the connection. In both cases the proxy server can grant, reject, redirect and alter connection requests as it likes. HTTP proxies are traditionally more HTTP protocol aware and do more high level filtering (even though that usually only applies to GET and POST methods, not CONNECT). SOCKS proxies can also forward UDP traffic and work in reverse: HTTP proxies cannot.
A typical SOCKS4 connection request looks like this:
SOCKS Client to SOCKS Server:
SOCKS Server to SOCKS client:
This is a SOCKS4 request to connect Fred to 66.102.7.99:80, the server replies with an "OK".
From this point on any data sent from the SOCKS client to the SOCKS server will be relayed to 66.102.7.99 and vice versa.
The command field can be 0x01 for "connect" or 0x02 for "bind". "bind" allows incoming connections for protocols like active FTP.
SOCKS4a is a simple extension to SOCKS4 protocol that allows a client that cannot resolve the destination host's domain name to specify it.
The client should set the first three bytes of DSTIP to NULL and the last byte to a non-zero value. (This corresponds to IP address 0.0.0.x, with x nonzero, an inadmissible destination address and thus should never occur if the client can resolve the domain name.) Following the NULL byte terminating USERID, the client must send the destination domain name and terminate it with another NULL byte. This is used for both "connect" and "bind" requests.
Client to SOCKS server:
Server to SOCKS client:
A server using protocol SOCKS4A must check the DSTIP in the request packet. If it represents address 0.0.0.x with nonzero x, the server must read in the domain name that the client sends in the packet. The server should resolve the domain name and make connection to the destination host if it can.
The SOCKS5 protocol is an extension of the SOCKS4 protocol that is defined in RFC 1928. It offers more choices of authentication, adds support for IPv6 and UDP that can be used for DNS lookups. The initial handshake now consists of the following:
The authentication methods supported are numbered as follows:
The initial greeting from the client is
The server's choice is communicated:
The subsequent authentication is method-dependent. Username and password authentication (method 0x02) is described in RFC 1929:
For username/password authentication the client's authentication request is
Server response for username/password authentication:
The client's connection request is
Server response:
Client software must have native SOCKS support in order to connect through SOCKS. There are programs that allow to circumvent this limitation: